In the field of network services, arrangements are known in which a company or other organization outsources the operation or maintenance of a domain name resolution platform. In those types of networks, the operator may engage a third-party provider which maintains or employs a set of domain name resolution servers (or name servers, for short) which operate to resolve requests to navigate to a domain name space. The name servers may be dedicated to supporting the domain name operations of that specific company or other organization, rather than a variety of domains at large. This arrangement can be referred to as managed domain name systems or services, or mDNS. The domain name service can in general receive a subject domain name, such as a domain name of the form “companyname.com,” and translate or resolve that name into a numerical Internet Protocol (IP) address or other value.
In known mDNS architectures, the third-party provider of the mDNS service may wish to monitor the performance and reliability of the overall network that includes the set of domain name servers in order to gauge the delivery of mDNS services, schedule maintenance of hardware or software, meter or bill those services, or perform other tasks. To perform those kinds of monitoring operations, the mDNS provider or other entity may deploy a set of “probe” servers which monitor the availability and performance of the name servers and their underlying resolution services. The set of probe servers can be operated from an external vantage point to the name servers, and can capture and record system uptime, downtime, response times, and a variety of other network operations and performance data.
However, no tools are available to assist an administrator or other user in assessing, setting up, and operating the necessary probe servers for these types of monitoring network. To deploy a monitoring network, the administrator or other user may, for instance, have to manually estimate the number of probe servers needed to effectively monitor a given mDNS network, allow for the expected or predicted frequency of network failures and associated downtime (including those of the probe servers themselves), and provide for the ability of the overall mDNS network to scale or reduce as the demands of the underlying customer domain infrastructure change.
In trying to carry out those estimates and implementations, if an administrator or other user creates a smaller than needed estimate of the total number of probe servers, that scenario can create result in name service failures and/or failures in the monitoring operations, themselves. Conversely, when an administrator or other user creates a larger than necessary number of probe servers, that outcome can unnecessarily increase the overall costs of the network, create an excessive flow of messages between the probe servers and name servers, and place excessive burdens on service logging and disk space.
It may be desirable to provide methods and systems for configuring a probe server network using a reliability model, in which a set of analytic tools and automated resources can allow an administrator or other user to configure mDNS networks, including the complement of probe servers, on a managed or rationalized basis.